1. Plan

  • Généralités

  • Survol global de SysML

  • Spécificités

  • Etude de cas d’un robot Rover en partenariat avec eclipse

2. Qui suis-je ?

logo irit

3. Objectifs et attentes

  • Formation à SysML "pour novices"

  • Développer une étude de cas complet

  • Vous préparer au défi SysML-France de la Nuit de l’Info ;-)

Note

  • Je ne maîtrise pas tout SysML™.

  • Je sais que l’ingénierie système n’est pas votre spécialité ni votre cible

  • Dans l’environnement toulousain, ça peut servir…​

4. C’est quoi SysML?

Si vous voulez partir (ou lire vos emails) dans 5 minutes…​

5. Fiche d’identité

  • Date de naissance non officielle : 2001!

  • Première spécification adoptée à l’OMG™ : 19 septembre 2007

  • Version actuelle : 1.3 (12/06/2012)

  • Paternité : OMG™ / UML™ + INCOSE

  • Auteurs principaux :

    • Conrad Bock

    • Cris Kobryn

    • Sanford Friedenthal

      Logo officiel

      sysml

Note Version beta de la 1.4 disponible depuis avril 2014.

6. SysML, c’est…​

Un ensemble de 9 types de diagrammes

  • Diagrammes structuraux

    • Diagrammes de définition de blocs (bdd)

    • Diagrammes internes de blocs (ibd)

    • Diagrammes paramétriques (par)

    • Diagrammes de packages (pkg)

  • Diagrammes comportementaux

    • Diagrammes de séquence (sd)

    • Diagrammes d’activité (act)

    • Diagrammes de cas d’utilisation (uc)

    • Diagrammes d’états (stm)

  • Diagramme d’exigence (req)

Un profil UML™

C’est à dire une extension de cette notation, un ensemble de nouveaux concepts et éléments qui sont définis à partir des éléments de base d’UML™. Un exemple : le bloc SysML™ n’est qu’une redéfinition de la classe UML™.

Une notation

Une notation de plus en plus enseignée et connue et qui servira donc de plus en plus de référence à la modélisation des systèmes.

7. SysML, ce n’est pas…​

Une méthode

En effet, contrairement à ce que beaucoup pensent en l’abordant, SysML™ ne propose pas de démarche particulière de développement de système. C’est à la fois sa force (votre méthode existante pourra continuer à être utilisée) comme sa faiblesse car cette absence de guide méthodologique fait souvent défaut à son utilisation.

Un outil

Nous verrons en effet que SysML™ ne fait que ce qu’on veut bien en faire. Comme tout langage il est limité dans son pouvoir d’expression, mais surtout il reste une simple notation qu’il convient d’utiliser avec des outils et des démarches associées.

Un raton laveur

C’est juste pour voir ceux qui suivent.

Note

On ne dit pas "le SysML" mais tout simplement "SysML".

8. Pourquoi une nouvelle notation

A good notation has subtlety and suggestiveness which at times makes it almost seem like a live teacher.

— Bertrand Russell
The World of Mathematics (1956)

Il existe une notation qui se veut "unifiée" pour les modèles : UML™.

Néanmoins cette notation est peu adaptée pour l’Ingénierie Système :

  • UML 1.x était complètement inadaptée :

    • Principalement pour les systèmes d’information

    • Peu de liens entre les diagrammes

    • Peu de liens entre les modèles et les exigences

  • UML 2.x n’est pas beaucoup mieux si ce n’est :

    • Implication des ingénieurs systèmes pour sa définition

    • Introduction du diagramme de structure composite

En conclusion UML™ est une bonne base :

  • Standard De facto en génie logiciel

  • Fournit beaucoup de concepts utiles pour décrire des systèmes (même complexes)

  • Stable et extensible (grâce notamment au mécanisme de profile)

  • Beaucoup d’outils disponibles

Mais…​

  • Manque de certains concepts clés d’Ingénierie Système

  • Vocabulaire beaucoup trop « software » pour être utilisé par les ingénieurs systèmes (concept de classe ou d'`héritage` par exemple)

  • Trop de diagrammes (13 sortes)

9. Introduction à SysML

10. Différence avec UML

La figure suivante, tirée de la spécification, résume bien les liens entre SysML™ et UML™, à savoir que SysML™ reprend une partie seulement des concepts d’UML™ (appelée UML4SysML) en y ajoutant des concepts nouveaux.

diff
Figure 1. Liens entre UML et SysML

11. Qui est "derrière"?

Industrie

American Systems, BAE Systems, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, NIST, Northrop Grumman, oose.de, Raytheon, Thales, …​

Vendeurs d’outils

Artisan, EmbeddedPlus, Gentleware, IBM, Mentor Graphics, PivotPoint Technology, Sparx Systems, Vitech, …​

Autres organisations

AP-233, INCOSE, Georgia Institute of Technology, AFIS, …​

Tip

La liste complète des membres de l’OMG™ est accessible à l’URL : http://www.omg.org/cgi-bin/apps/membersearch.pl

12. Organisation des différents diagrammes

Figure4 1
Figure 2. Les 9 diagrammes SysML et leur lien avec UML
Figure4 1 bis
Figure 3. Version abrégée des diagrammes
Note
Définition : Types de diagrammes (OMG SysML v1.3, p. 170)

SysML diagram kinds should have the following names or (abbreviations) as part of the heading…​

13. Outils SysML

Il existe un certain nombre d’outils permettant de réaliser des modèles SysML. Voici une liste non exhaustive :

Vous trouverez sur Internet des comparatifs et des avis à jour sur les outils.

Ce que je voudrai souligner ici c’est l’importance du modèle comme "dépôt" (je préfère le terme anglais de repository) d’éléments de base en relation les uns avec les autres. C’est toute la différence entre le dessin et le modèle.

Warning

Attention toutefois à ne pas confondre ce que vous permet (ou pas) de faire l’outil et la notation elle-même. Les fabricants ont parfois pris des libertés ou bien n’ont pas complètement implémenté toutes les subtilités de la notation.

14. Cadre pour les diagrammes

Abordons quelques principes généraux de SysML™, c’est à dire des éléments indépendant d’un diagramme en particulier :

  • Chaque diagramme SysML™ décrit un élément précis (nommé) de modélisation

  • Chaque diagramme SysML™ doit être représenté à l’intérieur d’un cadre (Diagram Frame)

  • L’entête du cadre, appelé aussi cartouche, indique les informations sur le diagramme :

    • le type de diagramme (req, act, bdd, ibd, stm, etc. en gras) qui donne immédiatement une indication sur le point de vue porté à l’élément de modélisation (comportement, structure, etc.)

    • le type de l’élément (par exemple package, block, activity, etc.), optionnel

    • le nom de l’élément (unique)

    • le nom du diagramme ou de la vue, optionnel

pacemaker context

15. Le Package Diagram

Le diagramme de paquetage permet de représenter l'organisation des modèles en paquetages.

  • Il est identique à UML™, et classique pour les développeurs (java notamment)

  • Il permet d’organiser les modèles en créant un espace de nommage

16. Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

  • par hiérarchie "système" (e.g., entreprise, système, composant, …​)

  • par types de diagrammes (e.g., besoins, structure, comportements, …​)

  • par cycle de vie (e.g., analyse, conception, …​)

  • par équipes (e.g., architectes, [IPT], …​)

  • par points de vue (e.g., sécurité, performance, …​)

  • etc.

pkg organisation2
Figure 4. Exemple d’organisation simple (T, UK)
pkg organisation modelview
Figure 5. Représentation de cette organisation dans un outil (T, UK)
pkg organisation
Figure 6. Un autre exemple d’organisation (T, UK)
pkg topcased
Figure 7. Un autre exemple d’organisation (T, UK)

17. Les exigences

18. Représentation de base

Un Requirement en SysML™ n’est qu’un bloc particulier.

corde
Figure 8. Un Requirement en SysML (P)

19. Tableaux de Requirements

Les requirements sont habituellement stockés dans des tableaux (feuilles excel le plus souvent!). Il est donc recommandé par le norme et possible dans de nombreux outils de représenter les exigences sous forme tabulaire.

Note
Définition : Requirements Table (OMG SysML v1.3, p. 145)

The tabular format is used to represent the requirements, their properties and relationships…​
req table
Figure 9. Exemples tableau d’exigences (OMG SysML v1.3, p. 145)

20. Liens avec les outils

La plupart des outils modernes permettent le passage entre outils classiques de gestion des exigences (comme DOORS™) et outils de modélisation SysML™ (comme Modelio, illustré ci-dessous).

req modelio

21. Les Requirements properties

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

  • priority (high, low, …​)

  • source (stakeholder, law, technical, …​)

  • risk (high, low, …​)

  • status (proposed, aproved, …​)

  • verification method (analysis, tests, …​)

22. Les Requirements links

Les principales relations entre requirement sont :

Containment

Pour décrire la décomposition d’une exigence en plusieurs sous-exigences (⊕–). Typiquement dès qu’une exigence est exprimée avec une conjonction "et" ("La voiture doit être rapide et économe.").

Refinement

Pour décrire un ajout de précision ([refine]), comme par exemple une précision.

Derivation

Pour indiquer une différence de niveau d’abstraction ([deriveReqt]), par exemple entre un système et un de ses sous-systèmes.

23. Les Requirements links (suite)

req exp1

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme [satisfy] ou [verify], mais nous les aborderons dans la partie transverse.

topcased req connections

24. Les Requirements Diagrams

Voici un exemple de req un peu plus étoffé, tiré de la norme (voir aussi [rationale]) :

hsuv reqs1
rover reqs1
Figure 10. Exemple d’organisation (Rover)

25. Les Use Case Diagrams

req uc relation
UCGestionNotes
uc
zigzag

26. L’architecture du système

On abordera :

  • l’organisation du système et des modèles

  • les Block Definition Diagrams

  • les Internal Block Diagrams

  • les Parametric Diagrams (pour les contraintes physiques)

  • les Sequence Diagrams (diagramme de séquence système)

27. Block Definition Diagrams

pacemaker context
constraints

28. Propriétés

On peut différencier 4 types de propriétés d’un bloc :

value properties

Des caractéristiques (quantifiables), aussi appelées simplement values

parts

Les éléments qui composent le bloc (cf. Internal Block Diagrams)

references

Les éléments auquel le bloc a accès (via des associations ou des agrégations)

constraint properties

Les contraintes que doivent respecter les propriétés (nous les verrons plus en détail, cf. Parametric Diagrams).

Note

Les values sont ce qui se rapproche le plus des attributs de classes UML.

29. Associations entre blocs

Il existe deux types de relations entre blocs :

  • l’association (y compris l’agrégation et la composition)

  • la généralisation/spécialisation

30. Internal Block Diagrams

Un ibd décrit la structure interne d’un bloc sous forme de :

parts

Les parties qui constituent le système (ses sous-systèmes)

ports

Elément d’interaction avec un bloc

connecteurs

Liens entre ports

31. Parts

ibdDetailVoiture

32. Ports (SysML 1.2)

ibdExempleFlots
flots

33. Ports (SysML 1.3)

La nouvelle spécification OMG SysML v1.3 introduit les concepts de:

proxy port

Ils doivent remplacer les ports 1.2 (ports de flots et ports standards) en en reprenant les caractéristiques et en ajoutant la possibilité d’imbrication et de spécification renforcée.

full port

En fait il s’agit du même concept qu’une partie qui serait exposée à l’extérieur.

Note

Pour une discussion sur les différences entre les deux ports : http://model-based-systems-engineering.com/2013/09/23/sysml-full-ports-versus-proxy-ports/

34. Parametric Diagrams

Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML™ utilise trois concepts clefs :

  • Constraints (un type de bloc)

  • Parametric diagram (un type d'`ibd`)

  • Value binding

35. Contraintes

C’est un bloc particulier :

  • avec un stéréotype ≪constraint≫ (au lieu de ≪block≫)

  • des paramètres en guise d’attributs

  • des relations liant (contraignant) ces paramètres

bddContraintes

36. Diagramme paramétrique

C’est une forme particulière de Internal Block Definition

param

37. Value Binding

blockconf

38. Le comportement du système

39. Le Diagramme des Cas d’Utilisation

Le Diagramme des Cas d’Utilisation est un diagramme UML™ permettant de représenter :

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations

    • entre acteurs et Use Case

    • entre Use Cases

40. Cas d’Utilisation (Use Case)

Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

uc4

41. Sequence Diagrams

42. Généralités

Il permet de :

  • modéliser les interactions entre blocs

  • séquencer ces interactions dans le temps

  • représenter les échanges de messages

  • spécifier les scénarios des cas d’études

43. Diagrammes de séquence système

dss
Exemple de Diagramme de séquence

44. Exemple

dsexp1
Exemple de diagramme de séquence

45. Notions avancées

On peut également représenter des instructions itératives et conditionnelles au travers de cadres d’interaction :

  • loop (boucle)

  • alt (alternative)

  • opt (optionel)

  • par (parallèle)

  • region (région critique - un seul thread à la fois)

46. Lien entre UC, DSS et DS

La décomposition hiérarchique permet une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque cas d’utilisation (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les blocs composant le système (issus du bdd) collaborent pour réaliser le traitement demandé.

Diagramme d'UC
Le DSS correspondant
Le DS correspondant

47. Diagramme d’états

Un diagramme d'état

48. Diagrammes d’activité

act pcmk1

49. Diagramme paramétrique

param

50. Génération de documentation

La plupart des outils permettent de générer de la documentation. Pour les outils basés eclipse il est possible d’utiliser le plug-in GenDoc2.

GENDOC

51. Génération de documentation

GENDOC

52. Génération de documentation

Les outils commerciaux comme Rhapsody permettent de générer de nombreux formats.

Rhapsody

53. Animation de modèles et simulation

Animation

54. Animation de modèles et simulation

Animation

55. Animation de modèles et simulation

Animation

56. Trends

twitter2012
google2012 1
google2012 2
google2012 3

À noter également que l’OMG™ a réalisé en 2009 une enquête sur l’utilisation de SysML™ (cf. [OMG2009]) dont voici deux extraits :

survey2
survey4

57. Thanks!

questions

58. About…​

Document réalisé par Jean-Michel Bruel via Asciidoctor (version 1.5.1) de 'Dan Allen', lui même basé sur AsciiDoc. Pour l’instant ce document est libre d’utilisation et géré par la 'Licence Creative Commons'. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.